home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19960209-19960425 / 000228_news@columbia.edu _Tue Mar 19 09:28:40 1996.msg < prev    next >
Internet Message Format  |  1996-05-13  |  6KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id JAA23906 for <kermit.misc@watsun>; Tue, 19 Mar 1996 09:28:40 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id JAA03876 for kermit.misc@watsun; Tue, 19 Mar 1996 09:28:35 -0500 (EST)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: LF problem on Ckermit vax/vms and axp/vms talking to sco
  8. Date: 19 Mar 1996 14:28:26 GMT
  9. Organization: Columbia University
  10. Lines: 123
  11. Message-ID: <4imgaa$3p0@apakabar.cc.columbia.edu>
  12. References: <4ic3a7$568@cloner2.ix.netcom.com> <4icdcm$lm8@apakabar.cc.columbia.edu> <4ikhnk$714@ixnews3.ix.netcom.com>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14.  
  15. In article <4ikhnk$714@ixnews3.ix.netcom.com>,
  16. David Pollack  <adldata@ix.netcom.com> wrote:
  17. : In <4icdcm$lm8@apakabar.cc.columbia.edu> fdc@watsun.cc.columbia.edu
  18. : (Frank da Cruz) writes: 
  19. : >
  20. : >In article <4ic3a7$568@cloner2.ix.netcom.com>,
  21. : >David Pollack  <adldata@ix.netcom.com> wrote:
  22. : >: I have ckermit 5a(190) running on digital vms (vax and alpha)
  23. : >: using a script to connect to an sco unix system.
  24. : >: 
  25. : >: From the vax, it works fine. the script waits for the logon 
  26. : >: prompt,sends the logon id, wait for the password prompt, 
  27. : >: sends the password, does what it needs to. This is repeatable.
  28. : >: 
  29. : >: From the alpha, it connects, waits for the logon script, sends 
  30. : >: the logon id, waits for the password prompt, never gets/sees 
  31. : >: it and times out. This is repeatable.
  32. :
  33. : > [response deleted...]
  34. :
  35. : Your response appears to be for connecting TO a VMS system. I am 
  36. : trying to go from vms (vax and alpha) to a unix system. I tried 
  37. : your suggestion and and got the same results from both systems:
  38. : 
  39. :  ************ extract starts ***********
  40. : $9$DKA0:[dirname] C-Kermit>set term debug on
  41. :  ........ dialing sequence ..........
  42. : CONNECT
  43. :   
  44. :  Call complete: 14:30:07.
  45. : $9$DKA0:[AARON] C-Kermit>c
  46. : 
  47. : -------------- from the alpha -----------------------
  48. : Connecting to _AXP$OPA1:, speed 9600.
  49. : The escape character is ^\ (ASCII 28).
  50. : Type the escape character followed by C to get back,
  51. : or followed by ? to see other options.
  52. : (Session logged to kmsess.log)
  53. : Debugging Display...)
  54. : ^J^M^JECSS^M^J^J^MWelcome to SCO Open Server Enterprise System Release
  55. : 3.0^J^M^
  56. : ^JECSS!login: feelxxx^M^JPassword:^M^JLogin incorrect^M^Jlogin:
  57. : ^M^Jlogin: +++^M
  58. : ^JPassword:^M^JLogin incorrect^M^Jlogin: ^M^Jlogin: +++^M^JOK^M^J
  59. : 
  60. : --------- from the vax system ------------------------
  61. : Connecting to _VAX$TXA4:, speed 9600.
  62. : The escape character is ^\ (ASCII 28).
  63. : Type the escape character followed by C to get back,
  64. : or followed by ? to see other options.
  65. : (Session logged to kmsess.log)
  66. : Debugging Display...)
  67. : ^J^M^JECSS^M^J^J^MWelcome to SCO Open Server Enterprise System Release
  68. : 3.0^J^M
  69. : ^JECSS!login: feelxxx^M^JPassword:^M^JLogin incorrect^M^Jlogin:
  70. : +++^M^JOK^M^J
  71. : *************** extract ends ***********
  72. : 
  73. : anyway: Both systems have always worked fine in manual mode, 
  74. : my problem is logging on using scripts. 
  75. : 
  76. : -Manually, pressing return sends a both CR and LF. Everything
  77. :     works fine.
  78. : -When the script issued a CR after the logon ID, it works on 
  79. :    the vax but not on the alpha. I can't figure out why.
  80. : -Trying to find out what happened, I did "set mac echo on" on the
  81. :    alpha. The problem no longer occurred. "set mac echo off"
  82. :    made the problem show up again. This does not make sense.
  83. : -When the script issued both CR and LF after the logon ID, It 
  84. :    worked on both vax and alpha.
  85. : 
  86. : Any explanation about the difference dialing out from the vax 
  87. : and alpha would be appreciated.
  88. : 
  89. OK, I think I'm awake this time.
  90.  
  91. But I can't explain the difference without some additional information.
  92. The business about having to send LF after a CR is not normal for a
  93. serial connection, and makes it sound more like a TELNET connection.  So
  94. the question is: what is on the other end of the dialup connection?  Is
  95. it a terminal server that uses TELNET protocol to communicate with the
  96. SCO system?  Is it the same terminal server in both cases?
  97.  
  98. TELNET protocol says that carriage returns, when used to indicate the end
  99. of a line or command, must be sent as CR and LF, to distinguish them from
  100. carriage returns used for overstriking, which are to be sent as CR
  101. followed by NUL.  Thus if you are dialing a terminal server that uses
  102. TELNET to get to the Alpha, then it would appear that the terminal server
  103. is not doing the proper CR -> CRLF conversion.  Presumably you could fix
  104. the terminal server's configuration and the problem would go away (and if
  105. you can, you should), otherwise you have to send the extra LF yourself, as
  106. you have done in this case.
  107.  
  108. You can also force EVERY CR to be sent as CRLF by giving the following
  109. command to C-Kermit:
  110.  
  111.   set terminal newline-mode on
  112.  
  113. So that's one possible explanation.  However, the fact that "set macro
  114. echo on" makes the problem go away raises additional suspicions that point
  115. in the direction of a timing problem.  These tend to occur when your
  116. script "types ahead" and the application that your script is talking to
  117. clears its input buffer of the material that your script has sent to it in
  118. advance of when it is requested, and this happens most often during the
  119. login process, as a security precaution against cracking programs.
  120.  
  121. Now your script is not "typing ahead", but there is still that split
  122. second between the time the host clears its buffer and when it's safe
  123. to start sending characters again.  Sometimes all you need is the
  124. judiciously-placed PAUSE command, e.g.:
  125.  
  126.   input 20 Username:
  127.   if fail stop 1 No username prompt
  128.   output \m(myusername)\13
  129.   input 10 Password:
  130.   if fail stop 1 No password prompt
  131.   pause 1
  132.   output \m(mypassword)\13  
  133.  
  134. If none of this helps, then get back to me directly and we'll go into
  135. it more deeply.
  136.  
  137. - Frank